I have merged the PR with the 14.2 tests. Can you merge Head into this PR please.

@danmar does Cppcheck supports multiple variables declaration in for scope? I found that j variable was not generated in XML dump at these lines: https://github.com/danmar/cppcheck/pull/2409/files#diff-dee0960ff8ec5a1387684d43113107a4R494-R497.

N1750 allows this declaration at 6.8.5.3:

158. Thus, clause-1 specifies initialization for the loop, possibly declaring one or more variables for use in the loop;

@danmar does Cppcheck supports multiple variables declaration in for scope? I found that j variable was not generated in XML dump at these lines:

Yes of course we should support that. Something is missing in cppcheck for that. Strange that we have not noticed before! Awesome find! 👍

I created the ticket https://trac.cppcheck.net/ticket/9516

I am still not sure about the getLoopCounterVariables. As far as I see, your current code says that there are no loop counter variables here:

for (x = 0; x < 10; x++)

Section "8.14" in the misra pdf contains a definition for a loop counter variable;

• it has scalar type
• Its value varies monotonically on each iteration of a given instance of a loop; and
• it is involved in a decision to exit the loop

So for instance, there is no loop counter variable here:

for (x=0; y < rand(); z++) {}

@danmar that's right, this PR adds an additional check for variables that defined in the first clause of for loop. This is required to avoid some false negatives in current implementation.

We can add more checks for loop counters from outer scopes and loop control flags defined in MISRA document as well. But it will be a bit more complicated due to lack of concrete examples and some unclear definitions in MISRA. I suppose it should be implemented incrementally in other PRs.

if I have to choose false negatives or false positives I'd choose false negatives. We can definitely try to solve this incrementally... if there are no false positives and we reduce false negatives.

Do you believe that there will not be false positives caused by this PR?

To avoid false positives it seems to me that the getForLoopCounterVariables should only return a variable that meets all the specified requirements. To check it is involved in a decision to exit the loop, I guess it's enough to check if it's used anywhere in second for loop expression.

I think I got what you mean. Are you about the case when we declare variable in first clause of for loop and it's value doesn't involved in decision to exit loop? This variable doesn't satisfy loop counter definition for MISRA document and it's modification is allowed. Something like this:

int y = 0; // loop counter
for (int i = 0; y < 10; y++) {
  i++; // 14.2. false positive?
}

Am I right?

But in this case we should generate violation of rule 14.2 in for loop, according following restrictions:

First clause which
• Shall be empty, or
• Shall assign a value to the loop counter, or
• Shall define and initialize the loop counter (C99).

So we want:

int y = 0;
for (int i = 0; y < 10; y++) { // 14.2. violation in first clause
  i++; // no warning
}

And in the following case:

int y = 0;
for (int i = 0; y < 10; y++) {
  if (++i > 5) { // 14.2
    break;
  }
}

i variable is completely satisfies loop counter definition, but there is modification in loop body. So, we need to generate violation in if line.

Okay, I'll check it a little later.

yes I agree with that.

@danmar I've corrected it according to your review.